Buffer Delay Reduction
Channel Change may take several seconds. One of the biggest factors is the time between the transmission of a video random access point and its decoding time, referred also as the buffer delay. Advanced encoders use such buffering to simplify their rate control and to allow maintaining quality when the content becomes harder to encode—they send the larger pictures over more time rather than using higher BR taking advantage of the time covered by the already buffered data. This problem is taken to the extreme with new coding specifications allowing encoders to generate decoding delay of up to 10 seconds.
FIG. 1 illustrates portion 10 of video. It includes video frames 10, 20, 30 and 40 that are delimited by boundaries 12, 22, 32 and 42, packets 10(1)-10(j) of frame 10, packets 20(1)-20(k) of frame 20, packets 30(1)-30(l) of frame 30, packet 40(1) of frame 40, and a decoding time stamp 50 that “falls” on packet 30(l).
Boundary 12 is the start of a random access point (also referred to as rap point). Packet 10(1) has is associated with the following timing information: program time stamp (PCR)=0, decoding time stamp (DTS)=1200 mS (mili-second) and presentation time stamp (PTS)=1290 mS. Packet 10(j) includes PCR=100 mS, packet 20(2) includes PCR=200 mS, packet 30(2) includes PCR=700 mS.
Packet 30(l) has a PCR of about 1200 mS and hence DTS of frame 10 “falls” on it. In this example the buffer delay equals 1200 mS-1200 mS will pass between the reception of packet 10(1) and its decoding. It is noted that the DTS of frame 10 can fall on other packets and not necessarily on the last packet of frame 30.
There is a growing need to reduce the delay introduced by the buffer delay.
Bit Rate Allocation
In IPTV environments, most of the broadcast streams are multicast in order to save bandwidth on the backbone. This way all users (viewers) that want to watch the same program join the same multicast stream.
A problem occurs when the operator wants to provide a Fast Channel Change (FCC) feature to the users. If the users simply join a multicast stream they would begin receiving the stream at random points and not at random access points (such as I pictures in MPEG-2 and other standards). In this case these users would not experience a fast tune-in into the program. In order to overcome this, the operator buffers a part of the stream and when the user wants to change the viewed channel, the system streams—in unicast—data beginning with the last I picture. The unicast stream is transmitted at a high bit-rate. This continues until the point where the data to be unicast catches up with the data which is multicast. At this point, the user is instructed to leave the unicast stream and join the multicast stream. Transmitting unicast streams is therefore mandatory to enable FCC. However, unicast streams require additional bandwidth on the backbone. When many streams are transmitted there may not be enough bandwidth to serve all the different viewers. It is noted that there may also be a bandwidth shortage on a network elements such as a DSL line that is connected to a user premises.
One way of overcoming the problem is by allocating fixed bandwidth to the different multicast and unicast streams. Assuming that the multicast bandwidth or their maximum bandwidth is known, the system allocates the remaining bandwidth to a fixed number of unicast streams N. This means that only N viewers can receive a FCC service at any given time. Also, allocating a fixed bandwidth per unicast stream determines the period it will take until the unicast stream catches up with the multicast stream.